【資料公開】AWS Security Hub導入と運用の検討ポイント

AWS で作成したリソースのセキュリティチェックを行う AWS Security Hub のセキュリティ基準機能の導入と運用の検討ポイントをまとめた登壇資料を公開します。

#AWS Security Hub

#AWS

#資料公開

yhana

2022.09.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2022 年 9 月 14 日に開催したセミナー「クラウドセキュリティの最適解」におけるセッション「AWS Security Hub 導入と運用の検討ポイント」の資料公開です。AWS 環境のセキュリティチェックを行うサービスの導入ポイントについて、ブログでも説明します。

本セッションの内容は、クラスメソッド社内で AWS Security Hub の導入支援経験のあるメンバーが集まって、どのような進め方をしているかを共有するわいわい会の内容をまとめたものになります。

登壇資料では、始めに AWS Security Hub の概要や失敗したセキュリティチェックの対応例を記載していますが、ブログ版ではメインとなるセキュリティ基準「AWS 基礎セキュリティのベストプラクティス」の導入と運用の検討ポイントに絞って記載しています。

登壇資料の目次

AWS Security Hub の概要
セキュリティチェックの対応例
AWS Security Hub 導入と運用の検討ポイント ブログでも紹介
みんなでセキュリティ対策（合わせて読みたい資料） ブログでも紹介

概要について資料を見ていただくか次のブログが役立ちます。

AWS Security Hub 導入の各フェーズでやること

AWS Security Hub のセキュリティ基準機能を導入するために各フェーズでやることをまとめた図です。どのような状況でも「この通りにやれば完璧」というものではありませんが、導入を検討する際の一つの例としてご参考にしていただけると幸いです。

大きく「お試しフェーズ」「本格導入フェーズ」「運用フェーズ」の 3 つに分けており、以降では各フェーズのやることについて一つずつ解説していきます。

お試し導入フェーズ

まずはお試し利用を行うフェーズであり、やることは 2 つです

コントロール（セキュリティチェック項目）を把握
コストの把握

お試し導入は簡単で、まず AWS Security Hub のマネジメントコンソールからポチポチっと有効化できます。1 点注意として、AWS Config の利用が前提となっています。

簡単な設定がありますので「AWS 基礎セキュリティのベストプラクティス」を選択して「Security Hub の有効化」を行います。CIS AWS Foundations Benchmark や PCI DSS に従う必要がある場合は、他のセキュリティ基準の有効化も検討します。特に要件がない場合は、「AWS 基礎セキュリティのベストプラクティス」がおすすめです。対象としている AWS リソースが多く、アップデートも頻繁なためです。

お試しで AWS Security Hub を有効化するときは、メインで利用しているリージョンの他に、バージニア北部リージョンと普段利用していないリージョンも 1 つ以上有効化しておくとよいです。CloudFront や WAF の一部のチェック項目はバージニア北部リージョンのみで評価されるためです。また、普段利用していないリージョンで AWS Security Hub を有効化した際のコストも把握できるためです。

コントロール（セキュリティチェック項目）の把握

AWS 基礎セキュリティのベストプラクティスには 189 個のコントロールがあります（2022年9月12日時点）。

AWS Foundational Security Best Practices コントロール - AWS Security Hub

サービス別のコントロール数の分布は次の通りです。EC2 や RDS などの主要なサービスのコントロール数が多いことが分かります。

各コントロールには重要度が設定されており、重要度別にコントロールを色分けしたグラフが次の図です。最も高い重要度のCRITICALは全体の約 10%程度です。

重要度の定義はAWSユーザーガイドに記載があります

コントロールの結果を生成および更新する - AWS Security Hub

コントロールの確認に時間的な制約がある場合は、よく対象サービスの利用頻度や重要度で優先度をつけて確認を行います。

コストの把握

セキュリティ基準の料金はチェック回数による従量課金となります。

料金 - AWS Security Hub | AWS

事前に正確なコスト算出は難しいため、実際の利用料金を参考にします。設定画面からチェック回数とコストの予測を確認することができるため、お試し期間の間におおよそのコストを把握しておきます。

本格導入フェーズ

本格導入フェーズでは次の 4 つを検討します。

設定と無効化項目の検討
通知の検討
初期セットアップ方法の検討
修復作業の自動化の検討

設定と無効化項目の検討

AWS Security Hub の主な設定とコントロールの無効化について検討します。また、組織的に導入する場合はマルチアカウント管理についても検討します。

導入に向けて検討する設定内容

主な設定項目とおすすめ設定は次の通りです。

検討内容	おすすめの設定	補足説明
利用するセキュリティ基準	AWS 基礎セキュリティのベストプラクティス（他は必要に応じて）	-
有効化するリージョン	すべてのリージョン	SCP (Service Control Policy) で利用禁止しているリージョンを除外することもある
検出結果の集約先リージョン	メインで利用するリージョン	-
新しいコントロールの自動有効化設定	オン（有効）	デフォルトはオン

AWS Security Hub はすべてのリージョンで有効化することがベストプラクティスです。誤って普段利用していないリージョンでセキュリティを考慮できていないリソースを作成した場合などにおいて、そのリソースが危険な設定のまま放置されているリスクに気づくこともできます。

セキュリティ基準は、「AWS 基礎セキュリティのベストプラクティス」が対象としている AWS リソースが多く、アップデートも頻繁なことからおすすめです。

新しいコントロールの自動有効化は、コスト増加にも関係するため、その点を踏まえて検討します。

無効化するコントロールの検討

コントロール毎に無効化することができます。

無効化することにより、チェック対象外になること以外にコスト削減効果もあります。

無効化を検討する際に参考となる基準の例として次の項目があります。

自社のセキュリティポリシー/ガイドライン
コントロールの重要度
対象サービスの利用状況

例えば、社内のセキュリティポリシーで暗号化が必須ではない場合は、暗号化に関するコントロールの無効化を検討します。AWS において、データの暗号化はユーザーの責任のため暗号化はしておいた方がよいですが、本当に必要なコントロールのみを定着させることを優先する考え方もあります。

また、AWS のユーザーガイドに無効化する可能性があるコントロールが紹介されているため、合わせて確認します。

無効にする可能性のある AWS Foundational Best Practices コントロール - AWS Security Hub

マルチアカウント管理

組織的に AWS Security Hub を導入する場合はマルチアカウント管理も検討します。

AWS Security Hub にはコントロールのチェック結果を集約する機能があるため、CCoE などの AWS 全体を管理する組織の AWS アカウントに集約することができます。全体を管理する組織がある場合は、これまで紹介した設定の検討や無効化するコントロールの方針決めを統一した基準にするため、一元的に管理することをおすすめします。

初期セットアップ方法は後述します。

通知の検討

コントロールのチェック失敗をメールやチャットツールに通知することができます。ただし、何も考えずに全てを通知すると一度に何十通ものメールが届き、確認しなくなってしまいます。

そのため、重要度や社内セキュリティポリシーを参考に項目を絞ることを検討します。

通知の設定や通知項目のフィルター方法は次のブログが参考になります。

もし通知だけでは見逃しや放置の可能性がある場合は、チケット管理システムと連携させることもできます。

例として、Backlog 課題の起票を行うブログを紹介します。

初期セットアップ方法の検討

AWS アカウント発行時の初期設定をマネジメントコンソールで行うか自動化するか検討します。AWS アカウント数が少ない場合は手作業の設定も候補になりますが、アカウント数が数十アカウントと多い場合は自動化を検討します。

AWS CloudFormation で AWS Security Hub を有効化するだけなら簡単にできます。

AWSTemplateFormatVersion: 2010-09-09
Description: "Enable AWS Security Hub"

Resources:
  SecurityHub:
    Type: AWS::SecurityHub::Hub

ただし、現状の AWS CloudFormation では、有効化するセキュリティ基準の指定やコントロールの無効化といった設定には対応していません。例えば、CloudFomation で有効化した場合は「AWS 基礎セキュリティのベストプラクティス」と「CIS AWS Foundations Benchmark」の 2 つが有効状態となり、どちらか一方のセキュリティ基準のみを利用したい場合は、無効化する作業が必要となります。

AWS::SecurityHub::Hub - AWS CloudFormation

上記のため、次の方法・ツールが設定自動化の候補となります。

AWS CLI を用いたスクリプトによる設定
AWS Step Function, AWS Lambda による設定
Terraform による設定

Terraform においても AWS 基礎セキュリティと CIS の両方が有効化されますが、個別のコントロールの無効化に対応しています。

aws_securityhub_standards_control | Resources | hashicorp/aws | Terraform Registry

もしくは、サンプルソリューションとなりますが、AWS 提供の設定ツールもあります。

aws-samples/aws-security-hub-cross-account-controls-disabler

初期セットアップに関するブログを紹介します。

AWS Organizations 環境のブログです。

非 AWS Organizations 環境のブログです。

サンプルソリューションに関するブログもあります。

修復作業の自動化の検討

失敗したコントロールに対して AWS Lambda などを用いて修復作業を自動化することもできます。

修復の自動化は導入スピードを優先して運用フェーズで検討することもあります。特に、利用期間が長い AWS アカウントでは設定の自動化の影響を確認する時間がかかる場合があります。

独自の修復を作り込む前に試していただきたいのが、AWS が提供しているソリューションです。比較的簡単に導入できます。修復の開始をユーザーが実行することにより自動で修復が行われます。コントロールの失敗時に自動で修復されるのではなく、キックはユーザーが行い、その後の修復が自動となります（半自動という言い方のほうがしっくりきます）。